CPUBackend: Make guest RIP reconstruction offsets signed #4271
Conversation
bylaws
force-pushed
the
soff
branch
2 times, most recently
from
06ea691 to
1a7a93a
Compare
| @@ -875,6 +876,13 @@ CPUBackend::CompiledCode Arm64JITCore::CompileCode(uint64_t Entry, uint64_t Size | |||
| for (size_t i = 0; i < DebugData->GuestOpcodes.size(); i++) { | |||
| const auto& GuestOpcode = DebugData->GuestOpcodes[i]; | |||
| auto& RIPEntry = JITRIPEntries[i]; | |||
| #if defined(ASSERTIONS_ENABLED) && ASSERTIONS_ENABLED | |||
There was a problem hiding this comment.
The checks here are trivial (particularly compared to the two memory stores right after), so there's no need to restrict them to assertion-builds.
(Actually I'm just now realizing LOGMAN_THROW_A(A)_FMT are already defined as no-ops for non-ASSERTION builds, so adding this extra check here is doubly unnecessary :( )
There was a problem hiding this comment.
This seems to be a code pattern used throughout FEX, unsure why
There was a problem hiding this comment.
I don't see a reason either, but a bad pattern being widespread doesn't make a compelling reason to stick to it either way.
There was a problem hiding this comment.
Yeah I'll clean it up in general
There was a problem hiding this comment.
Besides, there's a certain irony in using __builtin_assume annotations for speculative performance gains only if the macro to enable expensive assertions is active.
There was a problem hiding this comment.
The pattern here of wrapping LOGMAN_THROW_{A,AA}_FMT usage in additional #if defined(ASSERTIONS_ENABLED) && ASSERTIONS_ENABLED wrappers only matters in non-trivial places.
Like in ThreadManager.cpp this happens because it ensures correctness by locking a mutex and walking an array. So it does both, but we don't want that mutex locking in release builds.
With multiblock enabled, host code generated from guest code with a lower address may be placed after host code generated from guest code with a higher address in a multiblock. As each guest RIP reconstruction entry is always relative to the one before it the offset needs to be signed to allow this.
With multiblock enabled, host code generated from guest code with a lower address may be placed after host code generated from guest code with a higher address in a multiblock. As each guest RIP reconstruction entry is always relative to the one before it the offset needs to be signed to allow this.